\chapter{Maintenance}\label{ch:maintain}

\section{Memory requirements}\index{memory}

\dalton\ is designed to exit gracefully if there is not enough
memory at some stage of the calculation.  Wherever possible, it
will indicate how much additional memory is required for this
particular section.  This does not exclude the possibility that
the calculation will use even more memory at later stages of the
calculation. If \dalton\ aborts in the response calculation, it
may be possible to proceed by resetting the number of
perturbations handled simultaneously (see 
Sec.~\ref{sec:abares}).  Otherwise, some redimensioning will be
necessary.

The program uses approximately 95 MB of static memory allocated as common
blocks and similar data structures. Most of the memory used during the
calculation is taken from a large work array. The size of this work
array\index{memory!scratch} is supplied to the program as a shell
variable, \verb|WRKMEM|\index{WRKMEM}.
How this is done is exemplified in the chapter on how to get started
(Chapter~\ref{ch:starting}). This makes it easy
to give the program the memory needed for a given calculation. If no
value to the shell 
variable is supplied, the program will use the default value
(64000000 words) which is
determined at installation time from the variable
\verb|INSTALL_WRKMEM|\index{INSTALL\_WRKMEM} in the preprocessor
directives\index{memory!scratch}.

\subsection{Redimensioning \dalton}\index{redimensioning \dalton}

Most of the \dalton\ program has in principle no limitations on
the size of the problem one can handle, apart from
physical memory requirements and available disc space. The default
version of the program can handle 8000 basis functions, 200 nuclei and
800 occupied orbitals and up to $i$ functions in the basis
set. However, most such settings are adjustable to suit your own
needs, at the expense of larger (or smaller of course) static memory
requirements. The following list contains the parameters it is
most likely that you will find a need for changing with the
corresponding include 
file in which the variable appears and a short description of what
it defines. However, we note that the program sometimes will
require the user to change other parameters not included in this
list, and these variables are then easily found in the include/
directory by ``grep'ing for'' its occurrence. After a
change is made to one or more include files, you need to
rebuild the program using the
command \verb|make|.

\bigskip

\begin{tabular}{lll}
\verb|MAXOCC| & \verb|maxorb.h| & Maximum number of occupied
orbitals.\index{occupied orbitals!max limit}\index{limits}\\
\verb|MXCORB| & \verb|maxorb.h| & Maximum number of contracted atomic
orbitals.\index{orbitals!max limit}\index{limits!orbitals}\\
\verb|MAXWOP| & \verb|infvar.h| & Maximum number of orbital
rotations.\index{orbital rotations!max limit}\index{limits}\\
\verb|MXPST| & \verb|mxpdim.h| & The parameter MXPST is the largest
allowed number\index{limits!CI string types} of \\
&& string types.  A string type is defined by a given number \\
&& of electrons in RAS1 and RAS3. So for a normal CAS or \\
&& FCI calculation there is only a single string type (all elec-\\
&&trons in for example RAS2). The number of string types \\
&& become large when one allows a large number of electrons \\
&& in  RAS3  and a large number of holes on RAS1. If the \\
&& number of  string types in a given calculation exceeds \\
&& MXPST the program stops, and informs the user to raise\\
&& MXPST.\\
\verb|MXCENT| & \verb|mxcent.h| & Maximum number of nuclear centers +
point charges + ghost orbital centers.\index{nuclei!change max number}\index{limits!number of nuclei}\\
\verb|MXQN| & \verb|maxaqn.h| & Maximum angular momentum + 1 ($l+1$) in basis
set.\index{limits!max l-quantum number in basis functions}\\
\verb|MXAOVC| & \verb|aovec.h| & Maximum number of basis function blocks for
a given nuclear center.\index{limits!number of basis function blocks}
\end{tabular}

\section{New versions, patches}

New versions will be announced on the Dalton
homepage \verb|http://www.daltonprogram.org|.

Between releases, bug fixes will be distributed as
patches\index{patches} to an
existing version. Although not frequently used in the past, we believe
this to be a more common approach in the future. New patches will be
freely available from the Dalton homepage.
Patches will normally be distributed in order to correct
significant errors. In case of minor changes, explicit
instructions on modifying the source file(s) may be given.

In general, users should not make local
modifications in the FORTRAN source code, as this usually makes it
much harder to incorporate the changes into subsequent versions.
It is more convenient to use the C preprocessor code.  Indeed, by
judicious use of local \verb|#define|\index{define} variables (this
is described in any book on C that also describes the C
preprocessor) it is often possible to isolate local
modifications\index{modifications} completely, making it much easier
to apply them to later
releases.

One may be interested in code that is newly developed\index{new
code} within the
\dalton\ author group, but not part of any release of the program. In
such cases, users are asked to take direct contact with one of the
authors of that code, and ask him/her for the new code
needed. Such requests are {\em not} to be sent to
\verb|dalton-admin@kjemi.uio.no|. Note also that this may lead to user
restrictions of the program not contained in the license agreement
signed for a released version of the program.

\section{Reporting bugs and user support}

The \latestrelease\ program suite is distributed to the computational chemistry
society with no obligations on the side of the
authors. The authors thus take no responsibility\index{responsibility}
for the performance
of the code or for the correctness\index{correctness} of the
results. This distribution
policy gives the authors no responsibility for problems experienced by
the users when using the \dalton\ program.

User support can be requested at \verb|https://gitlab.com/dalton/user-support|.
Note, that the Dalton and LSDalton programs are distributed for free
and without any guarantee of reliability, accuracy, or suitability for any
particular purpose. No obligation to provide technical or any other support is
expressed or implied. As time allows, the developers will attempt to answer support
issues and bug reports.

Bug reports\index{bugs} are to be reported via \verb|https://gitlab.com/dalton/user-support|
and will be dealt with by one of the authors, although no responsibility
on the promptness of this response is given. In general, serious bugs
that have been
reported and fixed will lead to a new patch\index{patches} of the program, distributed from the
\dalton\ homepage.

The \dalton\ program is developed in an anarchistic fashion, that is,
future releases of the \dalton\ program will contain code related to
areas where the authors have had their greatest interest
lately. User feedback on weak points of the code is welcomed.

We encourage users to supply their own
modifications\index{modifications} to the extent that
such extensions/modifications seem relevant to a larger number of
users of the program system. The authors will, however, take the
liberty of deciding whether a supplied extension will be incorporated
into the official version of the program or not.

Pre- and post-processing programs to the \dalton\ program are always
welcome, and will, if permitted by the author, be distributed along
with the program with the proper credits to the
author(s) or be made available from the Dalton homepage.
